The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Internet Protocol (IP) telephony is a technology that is being widely implemented and gaining widespread acceptance. However, IP telephony systems do, at times, experience quality and performance problems. For example, some types of problems that are typically encountered in IP calls include one-way speech, choppy voice quality, excessive echo, jitter (which is the variation in the time between packets arriving), absence of a dial tone, and inability to dial a number or break a dial tone.
In past approaches, when a user experiences such problems with a voice call, the user typically must contact a help desk personnel and explain the symptoms of the problem. The help desk personnel notes the problem and informs a system administrator, who may then identify and analyze the problem in an attempt to diagnose the technical source of the problem. Often, the administrator uses a network management system in the call analysis process. Examples of commercially available network management systems are CiscoWorks IP Telephony Environment Monitor (ITEM), Routed Wide Area Network Management (RWAN), and CiscoWorks LAN Management Solution (LMS) from Cisco Systems, Inc. of San Jose, Calif. In addition, an administrator may use agent software embedded in network devices, such as routers, for active monitoring of telephony-based network traffic. One example of a commercially available agent is Service Assurance Agent (SAA), which is embedded software within Cisco IOS devices and which performs active monitoring to provide a set of network performance measurements.
However, by the time the administrator is alerted and completes the call analysis process, hours may have passed. Therefore, in the interim period, the user may be left with a “deficient” telephony environment. Furthermore, IP telephony environment traffic is dynamically changing. Therefore, by the time the administrator completes the call analysis process, the network may have converged and the administrator has no indication of and cannot replicate the problem originally encountered and reported to the help desk.
One possible solution is to configure an NMS to continuously monitor all possible end-to-end call paths between all relevant IP phones, such as IP phones coupled to an enterprise network. Such a solution is not scalable and, therefore, not ideal because of the number of call paths that a given NMS may have to continuously monitor. For n phones, there are (n*(n−1))/2 possible call paths. Furthermore, monitoring the possible call paths involves monitoring the layer 2 and layer 3 activities for a given call path while not allowing generation of any calls via the given call path. Consequently, as the number of phones in a IP telephony environment increases, such a solution places an increasing burden on the NMS and increasingly wastes network bandwidth.
Based on the foregoing, there is a clear need for a scalable technique for initiating call analysis in an IP telephony environment as soon as a problem occurs.